Data Processing Apparatus with a Logic Processing Device for Processing Network Data Records Transmitted from a Plurality of Remote, Distributed Terminal Devices

ABSTRACT

A data processing apparatus for processing network data transmitted from a plurality of remote, distributed terminal devices, comprising: a logic processing device that: accesses, over one or more distributed networks, instructions that define initialization of a process of determining multi-user network sources and that specify to allocate one or more portions of a virtual record among the multi-user network sources by automatically simulating a digital exchange process in which the data processing apparatus is a receiving source to receive at least one of the one or more portions by a processing network.

CLAIM OF PRIORITY

This application is a continuation of U.S. patent application Ser. No.15/904,516, filed on Feb. 26, 2018, which is a continuation of U.S.patent application Ser. No. 14/035,548, filed on Sep. 24, 2013, whichclaims benefit of U.S. Provisional Patent Application No. 61/826,130,filed May 22, 2013, the contents of each of which are incorporated byreference in their entirety.

TECHNICAL FIELD

The techniques described herein generally pertain to a data processingapparatus with a logic processing device for processing network datarecords transmitted from a plurality of remote, distributed terminaldevices.

BACKGROUND

A credit card and/or a debit card is a payment card issued to users as asystem of payment.

SUMMARY

In one aspect of the present disclosure, a data processing apparatus forprocessing network data records transmitted from a plurality of remote,distributed terminal devices, comprising: a logic processing devicethat: accesses, over one or more distributed networks, instructions thatdefine initialization of a process of determining multi-user networksources and that specify to allocate one or more portions of a virtualrecord among the multi-user network sources by automatically simulatinga digital exchange process in which the data processing apparatus is areceiving source to receive at least one of the one or more portions bya processing network; obtains, from an issuer system that issued aphysical machine-readable device to a first user over the one or moredistributed networks, digital data from the plurality of remote,distributed terminal devices that are each different from each other,with an item of the obtained digital data being indicative of a requestto approve a digital exchange process initiated with the physicalmachine-readable device, with the item of obtained digital datacomprising identifying data of the first user who initiated the digitalexchange process, a unique identifier of the physical machine-readabledevice and a field value specifying an amount of the digital exchangeprocess, and with the first user having a first data record stored on adata repository of one or more computer systems; wherein the item ofobtained digital data is obtained in response to a system of theprocessing network detecting that a physical machine-readable devicerepresented by the unique identifier is a specified type of physicalmachine-readable device to correlate a digital exchange process with themulti-user network sources; a correlation engine that determines a matchbetween (i) the unique identifier included in the item of digital datareceived from the processing network, and (ii) a unique identifierassociated with the first data record of the first user; based on thematch between the unique identifiers and based on execution of theobtained instructions, identifies a virtual record for the digitalexchange process that is associated with the first data record of thefirst user, wherein the virtual record comprises an electronic mechanismthat implements multi-user network sources to source a particulardigital exchange process; automatically correlates (i) the field valuereceived from the processing network, with (ii) the virtual record, withthe field value being correlated with the virtual record independent ofuser input of the amount of the digital exchange process; an executablelogic engine that receives, from a client device of the first user,allocation information requesting that the field value correlated withthe virtual record be allocated between at least the first user and asecond user, with the data processing apparatus differing from each ofthe client device and a point of sale device processing the digitalexchange process; following receipt of the allocation information:determines, based on the identifying information of the first user andthe allocation information, that portions of the field value are to beassigned to at least a first one of the multi-user network sourcesassociated with the first data record of the first user and a second oneof the multi-user network sources associated with a second data recordof the second user; determines, based on the amount of the digitalexchange process specified by the item of digital data obtained over theone or more distributed networks, a portion of the field value withwhich one or more fields in the second data record are modified; basedon executing the obtained instructions, automatically simulating, adigital exchange process in which one or more fields in one or more datarecords stored in the data processing apparatus are modified to includethe determined portion of the field value, wherein approval for eachuser record for the digital exchange process is received during thesimulation; and a transmission engine that correlates the first datarecord with the second user allocation amount specified by the item ofdigital data obtained over the one or more distributed networks and thatincludes computer code for using the second user allocation amount withwhich the first data record is correlated to enhance the first datarecord by: automatically causing, based on the simulating and inresponse to receiving the approval, the first data record to be modifiedwith an entry specifying a transmission of the determined portion of thefield value from the second data record to the first data record and thesecond data record to be modified with an entry representing thetransmission to the first data record of the determined portion of thefield value amount independent of input from the second user specifyingthe determined portion of the field value, wherein the modification ofthe first and second data records occur substantially simultaneously.

All or part of the foregoing may be implemented as a computer programproduct including instructions that are stored on one or morenon-transitory machine-readable storage media, and that are executableon one or more processing devices. All or part of the foregoing may beimplemented as an apparatus, method, or electronic system that mayinclude one or more processing devices and memory to store executableinstructions to implement the stated functions.

The details of one or more embodiments of the subject matter of thisspecification are set forth in the accompanying drawings and thedescription below. Other features, aspects, and advantages of thesubject matter will become apparent from the description, the drawings,and the claims.

DESCRIPTION OF DRAWINGS

FIG. 1A is an example of a conceptual environment for implementation ofa virtual tab.

FIGS. 1B, 2-6 and 9 are screen images of graphical user interfaces thatare rendered with information generated by a system for determiningmulti-user funding sources.

FIG. 7 is an example of a conceptual environment for determining fundingsources for a transaction.

FIG. 8 is a block diagram of a system for determining multi-user fundingsources.

FIG. 10 is a block diagram of components of the system for determiningmulti-user funding sources.

FIG. 11 is a flow chart of a process executed by the system fordetermining multi-user funding sources.

DETAILED DESCRIPTION

A system consistent with this disclosure allocates (e.g., automatically,evenly and/or based on pre-determined amounts) the cost of a transactionamong a plurality of users of the system. In an example, the systempromotes crowd spending. Generally, crowd spending includes thesplitting and sharing of a cost (e.g., for a good or a service) amongtwo or more people.

Referring to FIG. 1A, a conceptual environment 100 for implementation ofa virtual tab is shown. Generally, a virtual tab (hereinafter “tab”)includes a payment mechanism that implements multi-user funding sourcesto pay for a particular transaction. Generally, multi-user fundingsources enable a cost of a transaction to be allocated over a pluralityof users. Conceptual environment 100 includes users 102, 104, 106 andsystem 120. In this example, system 120 includes a system for generatingand opening a tab, including, e.g., tab 110.

In the example of FIG. 1A, users 102, 104, 106 participate in atransaction together, e.g., eat a meal together at a restaurant. In thisexample, the transaction is associated with a total transaction amount108 (e.g., the cost of the bill at the restaurant). In this example,user 102 has a payment card 112, which enables user 102 to pay for thetransaction. In this example, user 102 has a user account with system120. In this example, upon issuance of payment card 112 to user 102,user 102 enrolls payment card 112 in system 120, e.g., to enable usingpayment card 112 to pay tabs. In this example, payment card 112 isassociated with activation and deactivation features, e.g., to enableactivation and deactivation of payment card 112 and/or an accountassociated with payment card 112. Payment card 112 may also bere-activated and/or associated with a personal identification number(PIN) that may be entered prior to use of payment card 112. In anexample, user 102 can enable or disable PIN-less purchases on paymentcard 112, e.g., purchases that are made via payment card 112 withoutentering the PIN.

Payment card 112 is associated with the user account for user 102, e.g.,to link payment card 112 to user 102 in system 120. For example, theuser account includes the card number for payment card 112. System 120also enables user 102 to open tab 110 for the transaction. In thisexample, tab 110 is also associated with the user account for user 102.For example, tab 110 is associated with a string of uniquely identifyingnumbers and system 120 updates the user account for user 102 with thestring of uniquely identifying numbers. Subsequent to opening tab 110,user 102 invites users 104, 106 to join tab 110, e.g., to promoteallocating (e.g., evenly) total transaction amount 108 among users 102,104, 106. As described in further detail below, users 104, 106 acceptthe invitation and join tab 110.

In this example, payment card 112 includes a credit card, a debit card,and so forth. As previously described, payment card 112 is associatedwith the account of user 102 on system 120. In this example, user 102pays the total transaction amount 108 on payment card 112 (e.g., byallowing the restaurant to charge payment card 112 for the totaltransaction amount 108). As described in further detail below, followingcharging of payment card 112 for the total transaction amount 108,system 120 receives a message notifying system 120 of the charge and thetotal transaction amount 108 of the charge. The received messageincludes the card number for payment card 112. Using the card number forpayment card 112, system 120 determines that payment card 112 isassociated with tab 110 of user 102. In this example, tab 110 representsa request to allocate (e.g., evenly) total transaction amount 108 amongusers who choose to participate in the tab 110 (e.g., users 102, 104,106). In this example, system 120 allocates the total transaction amount108 among users 102, 104, 106, e.g., by charging allocation amounts 114,116, 118 to accounts associated with users 102, 104, 106, respectively.The associated accounts (that are charged for the allocation amounts)include payment cards that system 120 has on file, PayPal accounts,stored value accounts, bank accounts and so forth.

In this example, system 120 automatically and evenly allocates the totaltransaction amount 108 among users 102, 104, 106, e.g., independent ofuser 102 specifying an amount to be allocated to each of the otherusers. That is, system 120 automatically determines allocation amounts114, 116, 118, independent of user input other than setting up tab 110.

Referring to FIG. 1B, graphical user interface 150 is for opening a tab,e.g., for user 102 (FIG. 1A) opening tab 110 on system 120. In thisexample, information for graphical user interface 150 is generated bysystem 120 and graphical user interface 150 is displayed on a clientdevice of user 102. Graphical user interface 150 includes control 152for turning a tab on and off. By turning a tab on, a user instructs thesystem to start a process of determining multi-user funding sources(e.g., credit cards of various users) to pay for a transaction. Byturning a tab off, a user instructs the system to cease the process ofdetermining multi-user funding sources to pay for a transaction.

Graphical user interface 150 includes funding user control 154,selection of which enables a viewer of graphical user interface 150 toselect one or more other users (e.g., users 104, 106 in FIG. 1A) to funda transaction. Through funding user control 154, a user may select oneor more pre-defined groups of other users (e.g., friends). Generally,friends refer to users with a social connection to another user in asocial networking graphical of a social networking platform. By enablinga user to select friends to join a tab, the system promotes security andprevents against fraud. For example, if friends of a user are joining atab, it is less likely that the user opening a tab is using an accountfraudulently. The user may specify these groups through the system,e.g., by generating different groups and by specifying which other usersto include in which groups. Graphical user interface 150 also includesopen tab control 156, selection of which enables a user to start a newtab. Graphical user interface 150 also includes portion 160 fordisplaying other tabs that are associated with the user and associatedtransaction amounts of the other tabs.

Referring to FIG. 2, graphical user interface 200 enables selection ofone or more users (e.g., users 104, 106 in FIG. 1A) who are invited tofund a particular transaction and participate in a tab. In this example,graphical user interface 200 is displayed following selection of fundinguser control 154 (FIG. 1B). Graphical user interface 200 includesportion 202, e.g., for display of names of the users that are includedin the group specified by funding user control 154. In another example,graphical user interface 200 may include names of users, e.g.,independent of the users being associated with a particular group.

Portion 202 includes selection controls 204 a, 204 b, 204 c, e.g., forselection of one or more users to be added to a tab. Graphical userinterface 200 also includes open tab control 206, selection of whichenables a user to start the tab, e.g., by inviting users to join thetab. Graphical user interface 200 includes card selection control 208,e.g., to enable the viewer of graphical user interface 200 to select aparticular payment card to use to pay for the viewer's portion of thetab. There are various types of payment cards, including, e.g., a debitcard and a credit card. As described in more detail below, the systemprovides a user with an account. The user can input, into the system,information indicative of one or more payment cards and/or bankaccounts. The system associates the input information with the user'saccount, e.g., to enable the user to use one of the payment cards as afunding source for the user's portion of the transaction.

In a variation of FIG. 2, during an invite, a user can take a photographand/or a video of the item (e.g., a physical product, a gift, a tangiblegood, and so forth) being purchased and send the photograph (and/or thevideo) to the invitees. In an example, the photograph can have a captionincluded for the recipient to read and review along with the photograph.In still another variation of FIG. 2, the users invited to join a tabmay enter credit card information into a mobile device of the cardholderof a funding source payment card 801 (e.g., a user who is inviting theother users to join a tab).

Referring to FIG. 3, graphical user interface 300 invites a user toparticipate in a tab (e.g., invites one or more of users 104, 106 toparticipate in tab 110). Graphical user interface 300 includes portion302 that specifies the type of tab the user is invited to participatein, e.g., an invitation to participate in crowd spending for purchasingtickets to a baseball game. Portion 302 includes the invitation toparticipate in the tab and a map 303 of the physical location at whichthe transaction takes place. Graphical user interface 300 includesreject control 304, selection of which sends to the system informationspecifying that the user (who is invited to participate in the tab) doesnot want to participate in the tab and is rejecting the invitation.Graphical user interface 300 also include accept control 306, selectionof which sends to the system information specifying that the user wantsto participate in the tab. Through selection of accept control 306, theuser is choosing to participate in the tab for the particulartransaction (e.g., the baseball tickets) and is giving the systempermission to charge (or otherwise debit an account of the user) for theuser's portion of the transaction. As described in further detail below,an amount of the total charge is evenly allocated among the users whochose to participate in the tab for the transaction. In this example,the system automatically and evenly allocates charges for thetransaction amongst the users. In another example, users may specify howmuch (and/or what percentage of the total charge) each user wants to becharged for his/her portion of the transaction.

In still another example, an invitation to participate in a tab mayinclude one or more verification controls (e.g., security controls).Generally, a verification control includes an operation or a mechanismthat confirms an identity of a user. Referring to FIG. 4, graphical userinterface 400 includes invitation 402 to join a tab. Invitation 402includes verification control 404, e.g., for a user to input a PIN thatis used by the system to verify an identity of a user who is acceptingan invitation to join a tab. There are various types of PINs that may beused to verify an identity. In an example, a user has an account on thesystem. In this example, the user's account may be associated with a PIN(e.g., an account PIN). In this example, upon viewing invitation 402,the user uses keypad 408 to input the account PIN into verificationcontrol 404 and selects pay control 406. Upon selection of pay control406, the account PIN entered into verification control 404 istransmitted to the system. Upon receipt of the transmitted account PIN,the system verifies that the transmitted account PIN corresponds (e.g.,matches) to an account PIN associated with the user account of the userwho is invited to participate in the tab via invitation 402. If thesystem determines a match, then the user is allowed to participate inthe tab. If the system is unable to determine a match, the systemnotifies the user that the user in unable to participate in the tab,e.g., due to the system being unable to verify an identity of the user.Graphical user interface 400 also includes decline control 410,selection of which specifies that the user in declining invitation 402to participate in the tab.

In an example, after a user swipes a payment card, the tab is activated,e.g., to promote processing of the payment for transaction. Referring toFIG. 5, graphical user interface 500 is displayed (e.g., on a clientdevice associated with a user), following charging of the transaction ona payment card. In this example, graphical user interface 500 includesconfirmation message 502 that notifies a user 102 that the tab is openedand will be closed after a total transaction amount is charged to apayment card. Confirmation message 502 includes map 504 that provides avisual indication of a geographic location in which the transaction tookplace.

As previously described, system 120 is configured to allocate portionsof a transaction amount to accounts and/or payment cards of varioususers. In an example, a user associates a payment card with the user'saccount on the system, e.g., to promote charging of the allocationamount to the payment card. Referring to FIG. 6, graphical userinterface 600 promotes adding of a payment card to a user's account.Graphical user interface 600 includes portion 602 to display for a usera type of payment card that is added to the user's account, e.g., basedon information input into portion 604. There are various types ofpayment cards, including, e.g., a Visa card, a MasterCard Card, and aDiscover card. Graphical user interface 600 includes portion 604 forinput of information indicative of a card number of the payment card.Graphical user interface 600 also includes portion 606 for input ofexpiration date information for the payment card. Graphical userinterface 600 also includes portion 608 for input of informationindicative of a card verification value (CVV) for the payment card.Graphical user interface 600 includes control 610, selection of whichcauses the information input into portions 602, 604, 606, 608 to besaved in a data repository and associated with the user's account in thesystem.

FIG. 7 shows conceptual environment 700 for determining funding sourcesfor a transaction. In this example, an amount of a transaction isallocated (e.g., evenly and automatically) among users 701, 733, 735. Inthis example, conceptual environment includes authentication process 728and funding source process 730, e.g., each of which occur simultaneouslytogether and/or nearly simultaneously together.

In this example, user 701 is issued a payment card 702 and has anaccount on system 120, e.g., for generating tabs. Payment card 702 isassociated with user 701 in system 120. In this example, user 701submits (712) account information for payment card (PC) 702 to merchant704, e.g., by allowing the merchant to charge payment card 702. Via anetwork (e.g., a credit card network), merchant 704 transmits theaccount information to the merchant's bank 706 (e.g., an acquiringbank). In response, the merchant's bank 706 requests (714) adetermination of the cardholder's bank (“CHB”). In this example, thecardholder is an owner of payment card 702 and is user 701. The requestis transmitted to the card network 708, e.g., an intermediary between anacquirer and an issuer to authorize credit card transactions. Generally,an acquiring bank (or acquirer) is the bank or financial institutionthat processes credit and or debit card payments for products orservices for a merchant. The acquiring bank card network 708 validatesthe security features of payment card 702 and sends the accountinformation to the cardholder's bank 710 for purchase approval.

In an example, the cardholder's bank 710 detects that payment card 702(associated with the account information) is a funding source paymentcard, e.g., a payment card that is associated with system 120 and isused for funding a transaction with multi-user funding sources. Forexample, the cardholder's bank 710 may be associated with a system thatholds information indicative of account information for various paymentcards. The system may also store associations among the various accountinformation and information specifying whether a payment card is issuedby system 120 and/or otherwise associated with system 120.

In response to detecting that payment card 702 is a funding sourcepayment card, the cardholder's bank 710 (and/or a system associated withthe cardholder's bank 710) transmits request 718 to system 120. In anexample, the request 718 includes a web hook request and includesinformation that identifies payment card 702 (e.g., a payment cardnumber) and also includes information that specifies an amount of thetransaction to be funded with multi-user funding sources. Upon receiptof request 718, system 120 implements process 730, e.g., to determinefunding sources for the transaction.

Using the information that identifies payment card 702, system 120identifies (e.g., in a data repository) that payment card 702 isassociated with user 701 and also identifies a tab that is opened byuser 701. System 120 identifies that users 701, 733, 735 have agreed toparticipate in the identified tab. System 120 evenly allocates thetransaction amount among users 701, 733, 735 through execution ofprocess 730. In particular, process 730 includes subprocess 732 forprocessing an allocation amount for user 733. Process 730 also includessubprocess 734 for processing an allocation amount for user 735. Process730 also includes subprocess 736 for processing an allocation amount foruser 701. In this example, system 120 executes each of subprocesses 732,734, 736 at a substantially simultaneous time (and/or at a simultaneoustime). Each of subprocesses 732, 734, 736 causes a processing of acharge in accordance with the allocation amounts for users 733, 735,701, respectively. System 120 causes the processing of the charge forthe allocation amount by simulating a transaction in which system 120 isa merchant to be paid the allocation amount. For example, for user 733,system 120 causes the allocation amount to be charged to user 733 byinitiating a new transaction in which the payment card for user 733 ischarged the allocation amount.

For subprocess 732, system 120 identifies a payment card, payment methodor payment account for user 733. For example, system 120 identifies acredit card that user 733 has specified should be used for charging theallocation amount. System 120 acts as a merchant and performs (740) asimulation of user 733 submitting information indicative of a paymentcard account to the merchant, which in this example is system 120. Inthis example, bank 756 is associated with system 120 and acts as themerchant bank. Merchant bank 756 requests (742) a determination of thecardholder's bank, which in this example is the bank that issued thepayment card that user 733 is using to charge the allocation amount. Therequest is sent to the card network 758 for the payment card that user733 is using to charge the allocation amount. The card network 758validates the security features of the payment card that user 733 isusing to charge the allocation amount and sends (744) a request forpurchase approval (e.g., of the allocation amount) to cardholder bank764 for the payment card that user 733 is using to charge the allocationamount. In response, cardholder bank 764 approves (746) the purchase andtransmits information indicative of the approval to card network 758. Inresponse, card network 758 transmits (748) the approval to merchant bank756. Merchant bank 756 transmits (750) the approval back to system 120,which completes (752) the transaction and completes subprocess 732. Uponcompletion of subprocess, the allocation amount that is allocated touser 733 is charged to the payment card specified by user 733 for use inthe tab.

For subprocess 734, system 120 identifies a payment card, payment methodor payment account for user 735. For example, system 120 identifies acredit card that user 735 has specified should be used for charging theallocation amount. System 120 acts as a merchant and performs (770) asimulation of user 735 submitting information indicative of a paymentcard account to the merchant, which in this example is system 120.Merchant bank 756 requests (772) a determination of the cardholder'sbank, which in this example is the bank that issued payment card thatuser 735 is using to charge the allocation amount. The request is sentto the card network 760 for the payment card that user 735 is using tocharge the allocation amount. The card network 760 validates thesecurity features of the payment card that user 735 is using to chargethe allocation amount and sends (774) a request for purchase approval(e.g., of the allocation amount) to cardholder bank 766 for the paymentcard that user 735 is using to charge the allocation amount. Inresponse, cardholder bank 766 approves (776) the purchase and transmitsinformation indicative of the approval to card network 760. In response,card network 760 transmits (778) the approval to merchant bank 756.Merchant bank 756 transmits (780) the approval back to system 120, whichcompletes (782) the transaction and completes subprocess 734. Uponcompletion of subprocess, the allocation amount that is allocated touser 735 is charged to the payment card specified by user 735 for use inthe tab.

For subprocess 736, system 120 identifies a payment card, payment methodor payment account for user 701. For example, system 120 identifies acredit card that user 701 has specified should be used for charging theallocation amount. System 120 acts as a merchant and performs (790) asimulation of user 701 submitting information indicative of a paymentcard account to the merchant, which in this example is system 120.Merchant bank 756 requests (791) a determination of the cardholder'sbank, which in this example is the bank that issued the payment cardthat user 701 is using to charge the allocation amount. The request issent to the card network 762 for the payment card that user 701 is usingto charge the allocation amount. The card network 762 validates thesecurity features of the payment card that user 701 is using to chargethe allocation amount and sends (792) a request for purchase approval(e.g., of the allocation amount) to cardholder bank 768 for the paymentcard that user 701 is using to charge the allocation amount. Inresponse, cardholder bank 768 approves (793) the purchase and transmitsinformation indicative of the approval to card network 762. In response,card network 762 transmits (794) the approval to merchant bank 756.Merchant bank 756 transmits (795) the approval back to system 120, whichcompletes (796) the transaction and completes subprocess 736. Uponcompletion of subprocess, the allocation amount that is allocated touser 701 is charged to the payment card specified by user 701 for use inthe tab.

In the example of FIG. 7, following completion of each of subprocesses732, 734, 736, system 120 generates response 719, which includesinformation indicative of approval for the total transaction amount tobe charged to payment card 702. System 120 sends response 719 tocardholder's bank 710. Based on contents of response 719, cardholder'sbank 710 (and/or a system associated therewith) approves (720) thetransaction and processes payment for the total amount of thetransaction. In an example, cardholder's bank 710 matches the cardnumber of payment card 702 that is included in response 719 to a paymentcard associated with a pending transaction in a database associated withcardholder's bank. Following identification of the appropriate pendingtransaction, cardholder's bank 710 (and/or a system associatedtherewith) transmits to the card network 708 (and/or a system associatedtherewith) information indicative of the approval of the identifiedtransaction. Card network 708 (and/or a system associated therewith)processes the transaction amount and transmits (722) to the merchant'sbank 706 (and/or a system associated therewith) information indicativeof the approval. The merchant's bank 706 (and/or a system associatedtherewith) transmits (724) to the merchant 704 (and/or a systemassociated therewith) information indicative of the approval. Thecardholder (e.g., user 701) completes (726) the transaction and receivesa receipt. In a variation of FIG. 7, response 119 may includeinformation specifying that the transaction is denied, at which pointthe transaction initiated by payment card 702 is not allowed to proceed.

System 120 implements various techniques in performing process 730 andin authorizing a transaction, e.g., by generating response 719 thatauthorizes a transaction. These techniques include a batch card-to-cardload technique, a batch card-to-card transfer technique, a pass throughtechnique, an activation/deactivation technique and a delayedallocation/re-allocation technique. In an example, system 120 implementsthe batch card-to-card load technique by accessing informationindicative of payment cards associated with users 701, 733, 735. In thisexample, system 120 accesses this information by accessing user accountsfor the respective users and identifying payment card information in theuser accounts. System 120 then charges each of the payment cards withthe respective allocation amounts for users 701, 733, 735, e.g., viasubprocesses 736, 732, 734, respectively. System 120 responds tocardholder's bank 710 with a Boolean value that indicates approval forprocessing of the transaction by a processing network and batches thepayments together.

In this example, the processing network includes a series of entities(and associated devices) that process a payment. The entities include anissuer (e.g., an issuing bank) and an acquirer (e.g., an acquiringbank). An issuing bank is a bank that offers card association brandedpayment cards directly to consumers.

In an example of batch card-to-card transfer, system 120 responds to thecardholder's bank 710 with card numbers (e.g., for users 701, 733, 735)and respective allocation amounts. Using the individual card numbers,the processing network loads an amount of funds that equals the totaltransaction amount onto payment card 702. System 120 then passes, to thecardholder's bank, authorization to charge the full amount of thetransaction onto payment card 702. Each of the payment cards of users733, 735 is also charged the respective allocation amounts (e.g., viasystem 120 or via the processing network). Because payment card 702 isassociated with user 701 and user 701 is using payment card to pay forthe entire transaction, user 701 is not charged an allocation amount.Rather, the allocation amounts that are charged to users 733, 735 areused to reimburse user 701 a portion of the total charge that isprocessed against payment card 702. In this example, the processingnetwork includes the issuing bank (e.g., the cardholder's bank) and theacquiring bank.

In an example of the pass through technique, system 120 responds to thecardholder's bank 710 with card numbers (e.g., for users 701, 733, 735)and respective allocation amounts. System 120 inserts the individualcard numbers back into the processing network by transmitting, to theprocessing network, card numbers for the payment cards and respectiveallocation amounts for the payment cards for processing by theprocessing network. The processing network then sends each individualcard's data to the respective issuer of the card for processing.

In an activation/deactivation technique, the card account numberassociated with payment card 702 is inactive unless authorized. In thisexample, system 120 batch charges the payment cards of users 733, 735,e.g., by charging each of the payment cards with the respectiveallocation amounts. System 120 approves each of the separatetransactions that are associated with the batch charging. System 120responds to the cardholder's bank 710 with a Boolean value (e.g., a truevalue or a false value) that activates payment card 702 until thetransaction (that is initiated by user 701) is complete.

In a delayed allocation/re-allocation technique, system 120 responds tothe cardholder's bank 710 with card numbers (e.g., for users 701, 733,735) and respective allocation amounts. The transaction initiated bypayment card 702 is re-allocated as a split purchase among multiplepayment cards, e.g., for users 701, 733, 735. For example, system 120may initially allocate the total transaction amount evenly among users701, 733, 735. One or more of users 701, 733, 735 may specify thathe/she is only agreeing to pay a different amount (e.g., a re-allocationamount) and request a re-allocation. Following the re-allocation, theprocessing networking sends approval to respective issuing banks forapproval.

Referring to FIG. 8, network environment 800 includes client devices802, 806, system 120, network 810, point of sale device 832, processingnetwork 830 and data repository 812. In this example, client device 802is associated with user 808 and client device 806 is associated withuser 804. In this example, system 120 generates data for graphical userinterfaces, including, e.g., one or more of graphical user interfaces150, 200, 300, 400, 500, 600 (FIGS. 1B-6, respectively). Using network810, system 120 transmits the data for the graphical user interfaces toone or more of client devices 802, 806. Using the transmitted data, aclient device renders a graphical user interface, including, e.g., oneor more of graphical user interfaces 150, 200, 300, 400, 500, 600 (FIGS.1B-6, respectively). Through network 810, system 120 receives data fromone or more of client devices 802, 806, including, e.g., instructions toopen a tab, instruction to invite users to join a tab, instructions toaccept a tab invitation, and so forth.

In the example of FIG. 8, system 120 generates user account 816 for user808. Using client device 802 and network 810, user 808 specifies paymentcard information 822 (e.g., a credit card number) to be associated withuser account 816. System 120 updates user account 816 with payment cardinformation 822. In this example, user 808 also owns a funding sourcepayment card 801. In this example, user 808 requested the funding sourcepayment card 801 through system 120 and system 120 facilitated issuanceof funding source payment card 801. In this example, user 808 alsoassociates funding source payment card 801 with user account 816, e.g.,by transmitting to system 120 funding source payment card information821 for funding source payment card 801 and information that uniquelyidentifies user account 816 (e.g., a user name). Upon receipt of fundingsource payment card information 821 and the information that uniquelyidentifies user account 816, system 120 updates user account 816 withfunding source payment card information 821. In this example, useraccount 816 includes funding source payment card information 821 andpayment card information 822. In this example, payment card information822 (and/or funding source payment card information 821) may be used tocharge (or credit) user 808 an allocated amount for a transaction.

Funding source payment card information 821 may be used to charge user808 for an entire transaction, e.g., when user 808 uses funding sourcepayment card 801 to pay for a transaction. In this example, user 808 maybe reimbursed by the other users, e.g., by crediting the payment cardspecified by payment card information 822 with the amounts that areallocated to and paid by the other users.

System 120 generates user account 818 for user 804. Using client device806 and network 810, user 804 specifies payment card information 826(e.g., a credit card number) to be associated with user account 818.System 120 updates user account 818 with payment card information 826.Information indicative of user accounts 816, 818 is stored, by system120, in data repository 812.

In this example, point of sale device 832 includes hardware and/orsoftware at a point of sale. Generally, a point of sale is the placewhere a retail transaction is completed. It is the point at which acustomer makes a payment to the merchant in exchange for goods orservices. At the point of sale the retailer would calculate the amountowed by the customer and provide options for the customer to makepayment. The merchant will also normally issue a receipt for thetransaction.

In this example, users 804, 808 are at the point of sale associated withpoint of sale device 832. For example, a geographic location for thepoint of sale is a restaurant and users 804, 808 are sharing a meal. Inthis example, user 808 sends a request (not shown) to system 120 to opena tab. The request includes identifying information for user account816, including, e.g., a user name of user 808 that is associated withuser account 816. In response, system 120 opens tab 814 and associatestab 814 with user 816. Using client device 802 and network 810, user 808sends to system 120 a request to invite user 804 to join tab 814. Theinvitation request includes a user name of user 804 that is associatedwith user account 818. In response, system 120 sends to client device806 an invitation to join tab 814. User 804 accepts the invitation andsystem 120 adds user 804 to tab 814 by associating user account 818 totab 814.

In this example, user 808 uses funding source payment card 801 to payfor a transaction at the point of sale. In this example, a merchant atthe point of sale charges the funding source payment card 801, whichcauses the processing network 830 to process payment for thetransaction, e.g., using one or more of the processes depicted in FIG.7. During processing of the payment by processing network 830,processing network 830 detects a funding source payment card is used topay for the transaction. For example, the issuing bank (included in theprocessing network 830) of the funding source payment card 801 may beconfigured to store a list of card numbers that are associated withfunding source payment cards. When the issuing bank receives the requestto approve the transaction, the issuing bank compares a card numberincluded in the request to the stored list. In response to detectingthat a funding source payment card 801 is used to pay for thetransaction, the issuing bank sends an allocation request 831 to system120. The sent allocation request 831 includes the card number (fundingsource payment card information 821) of the funding source payment card801 and the total amount of the transaction.

Following receipt of allocation request 831, system 120 determines amatch between the funding source payment card information included inallocation request 831 and funding source payment card information 821included in user account 816. Based on the determined match and theassociation between tab 814 and user account 816, system 120 determinesthat tab 814 is used to determine the multi-user funding sources for thetransaction. Using the associations between tab 814 and each of useraccounts 816, 818, system 120 determines that users 804, 808 areparticipating in tab 814. System 120 automatically allocates (e.g.,evenly) the entire amount of the transaction among users 804, 808, e.g.,by determining allocation amounts 820, 824. In this example, system 120automatically and evenly allocates the total amount of the transactionamong users 804, 808 independent of input from users 804, 808. Rather,user 808 only has to give a merchant access to charge funding sourcepayment card 801 to initiate the process of automatically anddynamically determining multi-user funding sources for the transaction.System 120 associates allocation amounts 820, 824 with user accounts816, 818, respectively.

In the example of FIG. 8, system 120 causes a processing of one or moreallocation amounts 820, 824 using one or more of the above-describedtechniques (e.g., a batch card-to-card load technique, a batchcard-to-card transfer technique, a pass through technique, anactivation/deactivation technique and a delayed allocation/re-allocationtechnique).

In an example of batch card-to-card transfer, system 120 approves thetransaction and send to processing network 830 information indicative ofthe approval, e.g., to enable processing network 830 to process payment.The entire amount of the transaction is charged to funding sourcepayment card 801, following the approval by system 120. In this example,because user 808 is initially charged for the entire amount of thetransaction via processing of the total payment amount on funding sourcepayment card 801, user 804 reimburses user 808 for a portion of thetotal charge that is attributable to user 804, e.g., allocation amount824. In this example, system 120 handles processing of allocation amount824, e.g., by initiating a new transaction for allocation amount 824,causing the payment card associated with payment card information 826 tobe charged the allocation amount 824 and causing user account 816(and/or a payment card associated with payment card information 822) tobe credited allocation amount 824.

In an example of batch card-to-card load, system 120 approves thetransaction and sends to processing network 830 information indicativeof the approval, e.g., to enable processing network 830 to approvepayment. Rather than the entire amount of the transaction being chargedto funding source payment card 801, following the approval by system120, each of users 808, 804 are charged allocation amounts 820, 824,respectively. System 120 approves the transaction of charging thepayment card associated with payment card information 822 allocationamount 820. System 120 also causes processing of charging the paymentcard associated with payment card information 822 allocation amount 820.System 120 also approves the transaction of charging the payment cardassociated with payment card information 826 allocation amount 824.System 120 also causes processing of charging the payment cardassociated with payment card information 826 allocation amount 824.

In a variation of FIG. 8, point of sale device 832 is associated with apoint of sale printer (not shown), e.g., a printer for printing outreceipts at the point of sale. In this example, an interception deviceis placed between point of sale device 832 and the point of saleprinter. In an example, the point of sale device 832 sends out serialdata (via a Universal Serial Bus (USB) port or a serial cable). Theinterception device is installed between point of sale device 832 andthe printer, intercepts specified data that enables to select individualcharges, and sends the intercepted data to users via a wirelessconnection and/or low frequency blue tooth. That is, the interceptiondevice uses wireless technology to intercept wireless point of sale toprinter communications. The interception device runs off DC power, a lowfrequency charge from the USB and/or serial cable. Data sent to usersfrom the interception device enables guests at restaurants, bars andsupermarkets to review an itemized digital receipt of their purchases.

The interception device enables a merchant to install a piece ofhardware that pushes an itemized receipt to users of an open tab. In anexample, a group opens a tab for a dinner meal. Each member of the grouporders his/her food. A waitress keys the order into the point of saledevice 832. The group eats and requests a check. A cardholder in thegroup gives his/her funding source payment card to the waitress toswipe. After swiping, the interception device recognizes the first name,last name and the last four digits on the funding source payment card.The interception device matches funding source payment card informationto funding source payment card information associated with a tab andtransmits a digital receipt to the participants in the group purchasewho are associated with the tab. Each of the members of the group gets apush notification of the receipt on his/her mobile phone. Each memberselects indicates what he/she ordered via touch to the screen or othermeans and then clicks okay. The users can view (e.g., in theirrespective mobile devices) the items being selected together and in-realtime. Once everyone submits, the cardholder signs the check. Everyone inthe group paid collectively for his/her meal and system 120 batches thepayments to send to the merchant and the acquirer.

For example, referring to FIG. 9, graphical user interface 900 displaysa visual representation of a receipt for a transaction, with variousline items for the individual purchases that are included in thetransaction. Graphical user interface 900 includes controls 902, 904,906, 908, 910, 912, 914, 916, each of which is associated with aparticular item that is included in the transaction. A user may selectone or more of controls 902, 904, 906, 908, 910, 912, 914, 916. Throughselection of one or more of controls 902, 904, 906, 908, 910, 912, 914,916, a user may specify which items the user individually consumed or isotherwise responsible for the inclusion in the transaction. Graphicaluser interface 900 includes control 918, selection of which causesinformation specifying which of controls 902, 904, 906, 908, 910, 912,914, 916 are selected and information specifying which particular itemsare associated with the selected controls to be transmitted from aclient device rendering graphical user interface 900 to system 120.Using the transmitted information, system 120 determines which items areattributable to a particular user and determines an amount of the totaltransaction that is attributable to the particular user in accordancewith the selected items. In this example, the allocation amount includesan amount of the total transaction that is attributable to theparticular user.

The interception device provides one or more of the followingadvantages. When a group eats out and has a large bill, they may putdown a payment card for each person. In this example, the merchant haswait staff collect the cards, run each card, build a card booklet, printa receipt, bring it to the table, pick up the card books, punch in eachtip for each card and then close the table. This takes time and alsocosts a great deal of money over time with swipe fees and processingfees. The interception device enables a table to pay with one card,making it more time and cost efficient for the merchant.

Referring back to FIG. 8, in another example, client device 802 maydownload from system 120 a funding source application, e.g., softwarethat is dedicated to communication with system 120. After installationof the funding source application, the funding source applicationcommunicates with system 120 to enable user 808 to register with system120, input profile information, and participate in group transactions.The profile information can include a user name, password, home address,and a link to a user's actual debit/credit card. User 808 can request afunding source payment card (e.g., funding source payment card 801). Afunding source payment card can be a physical card, e.g., a debit/creditcard, a reward card, or an electronic representation of a card, whichmay be displayed on a mobile device. The electronic representation ofthe card may include text and non-text, such as image data. The imagedata may represent a logo.

In one example, the funding source application enables the electronicrepresentation of the card to transfer data to the point of sale device832 using Near Field Communication (NFC) technology, enabling thefunding source payment cardholder to make simpler transactions, exchangedigital content, and connect electronic devices, such as the point ofsale device 832, with a touch.

In another example, the funding source application displays a matrixbarcode, such as a Quick Response Code (QR code), along with theelectronic representation of the card, enabling the funding sourcepayment cardholder to make simpler transactions, exchange digitalcontent, and connect electronic devices, such as the POS system, with atouch. In still another example, the funding source application displaysa barcode along with the electronic representation of the card, enablingthe funding source payment cardholder to make simpler transactions,exchange digital content, and connect electronic devices, such as thePOS system, with a touch.

In the example of FIG. 8, users 804, 808 are registered with the system120. User 808, who is a cardholder of funding source payment card 801,invites user 804 to make a group purchase, e.g., to pay for a dinnerthat users 804, 808 are attending, as previously described. In thisexample, user 808 has payment for goods and services linked to his/herpersonal credit card (associated with payment card information 822) inuser account 816. This card is used to fund the share of group expensesfor user 808. In an example, the invitation is sent from client device802 to system 120 via email or simple messaging service (SMS). System120 relays the invitation to client device 806. As previously described,user 804 has loaded debit card information into a payment portal onhis/her profile in the funding source application and does not have afunding source payment card.

Running the funding source application on client device 806, user 804accepts the invitation of user 808. The acceptance is handled by system120. Once the invitation is sent and accepted, the tab process generatestab 814, which includes a unique ID, that associates users 804, 808 witha specific purchase or transaction made or to be made by user 808.

User 808 uses the funding source payment card 801 to pay for the itemand/or service. Information indicative of notification and details ofthis card use are sent to system 120, which divides the total numericamount owed equally among the members of the tab, i.e., users 804, 808,and sends the amounts owed to the various credit/debit cards associatedwith the respective users. In one example, a user can use the fundingsource application to communicate with system 120 to pay a portion ofthe total amount due for the transaction. System 120 verifies that theamounts authorized for each user totals the amount due.

In some examples, a user has the ability to add a payment card he/shechooses to his/her funding source application (and to the respectiveuser account). If user 808 wishes, he or she can have his/her fundingsource payment card 801 linked to a credit card with certain rewards, abusiness credit card, business debit, personal debit and/or bankaccount. This feature allows for one single card to be carried in theuser's wallet or stored in his/her mobile device and the funding sourceapplication routes the users' decision of payment type via system 120.Funding source payment card 801 promotes having a single card in awallet or a single electronic version of a card in a mobile phone. User808 can open the funding source application on client device 802 andselect which card he/she loaded into system 120 (and associated withuser account 816) to be the source of payment. User 808 can choosebetween credit cards, debit cards or bank accounts to make payment. Bydoing so, user 808 is able to split a personal expense between two ormore of his/her cards that are in a digital wallet (e.g., user account816).

In an example, the funding source application (on client device 802)provides a security feature that allows user 808 to put his/her fundingsource payment card 801 in a status of active or inactive. Through asetting in the funding source application, the card can be turned “on”or in this case made active and can be used for payments. If user 808wishes, he or she can inactivate the card or “close” the funding sourcepayment card for periods of time between transactions. This allows forcontrol of the card in cases of loss, theft or personal choice. Thefunding source payment card can be used based on the choice of the user.

In some examples, system 120 includes a reverse geocode authenticationprocess. Generally, reverse geocoding includes a process of back(reverse) coding of a point location (latitude, longitude) to a readableaddress or place name. This permits the identification of nearby streetaddresses, places, and/or areal subdivisions such as neighborhoods,county, state, or country. In this example, the geographic locations ofeach of the users in an open tab, e.g., each user's geographic positionas specified by longitude and latitude coordinates, are analyzed (bysystem 120) when a transaction is initiated. If each of the users islocated in proximate geographic locations to each other (and/orgeographic locations within a specified distance to each other), system120 allows the processing of payment(s) for the transaction to continue.If one or more of the users is not located proximately to the group ofusers, system 120 disallows the transaction, e.g., by determining thepossibility of fraud. In another example, if system 120 determines amismatch between a geographic location of a user and geographic locationof another user or of the merchant, system 120 transmits to a clientdevice associated with the user, a message requesting authorization tocharge a specified allocation amount to the user account of the user.Upon receipt of the requested authorization, system 120 approves thetransaction and processing is continued.

When opening a tab, the funding source payment cardholder can select aduration of time for a tab to remain open for group transactions to bepaid for on the funding source payment card. In an example of a weekendtrip with multiple users, a user who opens the tab can specify that thetab remains open for three days following opening of the tab. Duringthat time frame, group transactions would be split between the membersof the tab and the tab is finally “closed” on the third day. In thisexample, the group transactions are allocated equally or proportionatelyto amounts each individual user spends (according to user selectedtransactions). In another example, a tab could be opened for a singlegroup transaction, or open for a few hours or for days.

Based on communications between the point of sale device 832 and system120, system 120 is configured such that when a tab is opened among usersat a restaurant, system 120 locates geographical locations of users whojoin the tab (“tab members”) via their mobile devices. In this example,system 120 sends requests to the funding source applications on themobile devices for the users to send information to system 120 thatspecifies the geographic locations of the respective users. Using thisgeographic location information, system 120 determines and confirms thatthe users are in the same location.

When the funding source payment card or an electronic representation ofthe funding source payment card is used for payment, the point of saledevice 832 causes a transmission (via one or more of network 810 andprocessing network 830) of a merchant identifier (ID) to system 120. Amerchant ID is a unique number assigned to a merchant account toidentify it throughout the course of processing activities. In thisexample, system 120 recognizes the merchant ID and matches a geographiclocation for the merchant ID to a geographic location of the users. Forexample, data repository 812 may store a listing of merchant IDs andassociated geographic locations. In this example, system 120 may look-upin the listing a geographic location that is associated with thetransmitted merchant ID. Based on the determined match betweengeographic locations, system 120 approves the transaction forprocessing.

In another example, following the match, the point of sale device 832sends the itemized receipt to the users who are participating in theopen tab. At that time, each user (via the funding source application onmobile devices) selects what he/she ordered during the meal. The mobiledevices send, to system 120, information indicative of items that eachuser has selected. Based on a user's selection of items, system 120determines a portion of the entire amount that is attributable to theuser. In this example, the funding source payment card user can pay withhis/her card and can be reimbursed for the other users' allocatedamounts or specified portions via charges processed by system 120. Inanother example, the funding source payment card user and other users inthe group can each pay for his/her portion directly through his/herfunding source application with the merchant/vendor. In some examples,the funding source application provides a financial dashboardhighlighting the usage of the user's funding source payment card andenabling the user to review statements, see spending trends and generatecustom alerts and notifications. Users can view how they spend withtheir friends and export these results to, for example, a spread sheet.

In another example, system 120 enables eCommerce and transactions whererespective users are not physically together or without mobile serviceby implementing the following technique. In this example, a user, who isopening a tab, selects other users who are not in a same or closegeographic location of the user who is opening the tab. In this example,system 120 implements Internet Protocol (IP) based tracking of a webpurchase for matching a geographic location of a point of sale with ageographic location of a mobile device. In this example, system 120determines a geographic location of a user who is requesting the openingof the tab, e.g., by receiving from a mobile device of the userinformation specifying the geographic location of the mobile device.System 120 also receives a merchant ID from point of sale device 832.Using the previous described listing in data repository 812, system 120determines a match between a geographic location associated with themerchant ID and a geographic location of a mobile device used by a userwho is requesting that the tab be open. Based on the determined match,system 120 opens a tab for the user and the remainder of the transactionprocessing proceeds independent of geographical location matching orverification.

Referring to FIG. 10, client devices 802, 806 can be any sort ofcomputing devices capable of taking input from a user and communicatingover network 810 with system 120 and/or with other client devices. Forexample, client devices 802, 806 can be mobile devices, smartphones,desktop computers, laptops, cell phones, personal digital assistants(“PDAs”), servers, embedded computing systems, and so forth.

System 120 can be any of a variety of computing devices capable ofreceiving data, such as a server, a distributed computing system, adesktop computer, a laptop, a cell phone, a rack-mounted server, and soforth. System 120 may be a single server or a group of servers that areat a same location or at different locations.

The illustrated system 120 can receive data from one or more clientdevices 802, 806 via input/output (“I/O”) interface 1002 (e.g., throughnetwork 810 and/or processing network 830). I/O interface 1002 can beany type of interface capable of receiving data over a network, such asan Ethernet interface, a wireless networking interface, a fiber-opticnetworking interface, a modem, and so forth. System 120 also includes aprocessing device 1008 and memory 1004. A bus system 1006, including,for example, a data bus and a motherboard, can be used to establish andto control data communication between the components of system 120.

The illustrated processing device 1008 may include one or moremicroprocessors. Generally, processing device 1008 may include anyappropriate processor and/or logic that is capable of receiving andstoring data, and of communicating over a network (not shown). Memory1004 can include a hard drive and a random access memory storage device,such as a dynamic random access memory, or other types of non-transitorymachine-readable storage devices. Memory 1004 stores computer programs(not shown) that are executable by processing device 1008 to perform thetechniques described herein.

Referring to FIG. 11, system 120 implements process 1100 in dynamicallydetermining multi-user funding sources. In operation, system 120receives (1102), from a processing network, a request to approve atransaction. In this example, the request includes identifyinginformation of a user who initiated the transaction (e.g., a card numberfor a funding source payment card, a user name, and so forth) and anamount of the transaction.

System 120 determines (1104) a tab that is associated with thetransaction. For example, using a card number for a funding sourcepayment card that is included in the approval request, system 120determines a user account that is associated with the funding sourcepayment card. System 120 identifies a tab that is associated with thedetermined user account. System 120 also determines (1106) allocationamounts, e.g., by evenly allocating the total amount of the transactionamong the users who have joined the tab. In another example, system 120disproportionately allocates the amount of the transaction among theusers who have joined the tab, e.g., by allocating to each user aportion of the transaction that is attributable to the user. In thisexample, each user sends to system 120 information specifying itemsincluded in the transaction that the user has ordered or otherwisecaused to be included in the transaction. In still another example,system 120 accesses, based on the identifying information of the userwho initiates the transaction, (i) information specifying that theamount of the transaction is to be allocated among a first user accountof the first user and one or more second user accounts of one or moresecond users (e.g., a tab), and (ii) information specifying anallocation amount for each of the user accounts associated with the tab.

System 120 causes (1108) each of the users who are members of the tab tobe charged respective allocation amounts, e.g., using one or more abatch card-to-card load technique, a batch card-to-card transfertechnique, a pass through technique, an activation/deactivationtechnique and a delayed allocation/re-allocation technique. System 120also transmits (1110), to the processing network, information specifyingapproval for the transaction.

Using the techniques described herein, a single payment cardcommunicates with a point of sale device or terminal and sends a receiptof the purchase to the funding source application and line items aresplit among a group of users, as described in U.S. Ser. No. 14/035,548,the entire contents of which are incorporated herein by reference. Apayment card is linked to single or multiple user accounts and paymentis split by user “opt in” and allocated evenly, e.g., while payment isprocessed simultaneously. Payment as a group is split among multipleusers by utilizing a payment card linked to a mobile application, whichprocesses group payment automatically and each user contributes his/hershare of payment. A payment card (e.g., a funding sourcing payment card)can have multiple cards, bank accounts and third party payment platformsregistered to the payment card. The system described herein enables anability to open/close a plastic card (or an electronic representation ofa funding source payment card) via a mobile application. This allows fora funding source payment card (or an electronic representation of afunding source payment card) to be “open” and/or available for purchasesand “closed” when not authorized for purchases, thus providing securityto a user.

In an example, the system includes an application programming interface(API) for integrating the system and the techniques described hereinwith a third-party application. In an example, a user chooses to make apurchase through the third-party application. Through the API, thethird-party application is configured to interface with the system.Following selection of the third-party application, the user is prompted(e.g., via the third-party application) to select other users (e.g.,friends) with whom to share the expense. Through the API, thethird-party application sends information indicative of the selection tothe system, which in turn, sends to the selected users an invitation toaccept or deny the invitation. If an invited user has the Tabapplication and accepts the invitation, the system automatically chargesthe invited user for his/her portion of the tab, e.g., using theabove-described authorization process and funding routing. If theinvited user does not have the Tab application (e.g., executing on amobile device), the invited user is promoted to download either the Tabapplication or the third-party application.

Embodiments can be implemented in digital electronic circuitry, or incomputer hardware, firmware, software, or in combinations thereof. Anapparatus can be implemented in a computer program product tangiblyembodied or stored in a machine-readable hardware storage device forexecution by a programmable processor; and method actions can beperformed by a programmable processor executing a program ofinstructions to perform functions by operating on input data andgenerating output. The embodiments described herein, and otherembodiments of the invention, can be implemented advantageously in oneor more computer programs that are executable on a programmable systemincluding at least one programmable processor coupled to receive dataand instructions from, and to transmit data and instructions to, a datastorage system, at least one input device, and at least one outputdevice. Each computer program can be implemented in a high-levelprocedural or object oriented programming language, or in assembly ormachine language if desired; and in any case, the language can be acompiled or interpreted language.

Processors suitable for the execution of a computer program include, byway of example, both general and special purpose microprocessors, andany one or more processors of any kind of digital computer. Generally, aprocessor will receive instructions and data from a read-only memory ora random-access memory or both. The essential elements of a computer area processor for executing instructions and one or more memory devicesfor storing instructions and data. Generally, a computer will alsoinclude, or be operatively coupled to receive data from or transfer datato, or both, one or more mass storage devices for storing data, e.g.,magnetic, magneto optical disks, or optical disks. Computer readablemedia and/or hardware storage devices for embodying computer programinstructions and data include all forms of non-volatile memory,including by way of example semiconductor memory devices, e.g., EPROM,EEPROM, and flash memory devices; magnetic disks, e.g., internal harddisks or removable disks; magneto optical disks; and CD ROM and DVD-ROMdisks. The processor and the memory can be supplemented by, orincorporated in special purpose logic circuitry. Any of the foregoingcan be supplemented by, or incorporated in, ASICs (application-specificintegrated circuits).

To provide for interaction with a user, embodiments can be implementedon a computer having a display device, e.g., a LCD (liquid crystaldisplay) monitor, for displaying data to the user and a keyboard and apointing device, e.g., a mouse or a trackball, by which the user canprovide input to the computer. Other kinds of devices can be used toprovide for interaction with a user as well; for example, feedbackprovided to the user can be any form of sensory feedback, e.g., visualfeedback, auditory feedback, or tactile feedback; and input from theuser can be received in any form, including acoustic, speech, or tactileinput.

Embodiments can be implemented in a computing system that includes aback end component, e.g., as a data server, or that includes amiddleware component, e.g., an application server, or that includes afront end component, e.g., a client computer having a graphical userinterface or a Web browser through which a user can interact with animplementation of embodiments, or any combination of such back end,middleware, or front end components. The components of the system can beinterconnected by any form or medium of digital data communication,e.g., a communication network. Examples of communication networksinclude a local area network (LAN) and a wide area network (WAN), e.g.,the Internet.

The system and method or parts thereof may use the “World Wide Web” (Webor WWW), which is that collection of servers on the Internet thatutilize the Hypertext Transfer Protocol (HTTP). HTTP is a knownapplication protocol that provides users access to resources, which maybe data in different formats such as text, graphics, images, sound,video, Hypertext Markup Language (HTML), as well as programs. Uponspecification of a link by the user, the client computer makes a TCP/IPrequest to a Web server and receives data, which may be another Web pagethat is formatted according to HTML. Users can also access other pageson the same or other servers by following instructions on the screen,entering certain data, or clicking on selected icons. It should also benoted that any type of selection device known to those skilled in theart, such as check boxes, drop-down boxes, and the like, may be used forembodiments using web pages to allow a user to select options for agiven component. Servers run on a variety of platforms, including UNIXmachines, although other platforms, such as Windows 2000/2003, WindowsNT, Sun, Linux, and Macintosh may also be used. Computer users can viewdata available on servers or networks on the Web through the use ofbrowsing software, such as Firefox, Netscape Navigator, MicrosoftInternet Explorer, or Mosaic browsers. The computing system can includeclients and servers. A client and server are generally remote from eachother and typically interact through a communication network. Therelationship of client and server arises by virtue of computer programsrunning on the respective computers and having a client-serverrelationship to each other.

Other embodiments are within the scope and spirit of the descriptionclaims. Additionally, due to the nature of software, functions describedabove can be implemented using software, hardware, firmware, hardwiring,or combinations of any of these. Features implementing functions mayalso be physically located at various positions, including beingdistributed such that portions of functions are implemented at differentphysical locations. The use of the term “a” herein and throughout theapplication is not used in a limiting manner and therefore is not meantto exclude a multiple meaning or a “one or more” meaning for the term“a.” Additionally, to the extent priority is claimed to a provisionalpatent application, it should be understood that the provisional patentapplication is not limiting but includes examples of how the techniquesdescribed herein may be implemented.

A number of exemplary embodiments of the invention have been described.Nevertheless, it will be understood by one of ordinary skill in the artthat various modifications may be made without departing from the spiritand scope of the invention.

1. (canceled)
 2. A data processing apparatus for processing network datarecords transmitted from a plurality of remote, distributed terminaldevices, comprising: at least one processor; and a memory storinginstructions that, when executed by the at least one processor, causethe at least one processor to perform operations including: receivingallocation information specifying an allocation of transaction amountsfrom among payment sources associated with a plurality of networkedclient devices; simulating a digital exchange process among theplurality of networked client devices for allocating the transactionamounts amount a first account associated with a first client device anda second account associated with a second client device by performingoperations comprising: performing a security authentication process foreach of the first client device and the second client device of thenetworked client devices by: receiving, for each of the first clientdevice and the second client device, a geo-code indicating a location ofthat client device; receiving identifier data indicating a terminaldevice that is physically associated with the digital exchange process,the terminal device being a non-mobile device associated with alocation; determining the location of the terminal device that isphysically associated with the digital exchange process based on theidentifier data indicating the terminal device; authenticating, from thegeo-code of each of the first and second client devices, that each ofthe first and second client devices is located within a specifieddistance to the location of the terminal device that is physicallyassociated with the digital exchange process; and determining whether toallow the digital exchange process to continue when the authenticatingindicates that each of the first and second client devices is locatedwithin the specified distance to the location of the terminal devicethat is physically associated with the digital exchange process;determining, based on determining whether to allow the digital exchangeprocess to continue and based on the allocation information, thetransaction amounts for assigning to at least a first payment sourceassociated with the first client device and a second payment sourceassociated with the second client device, the first payment source andthe second payment sources included in the payment sources; andsimulating the digital exchange process among the first payment sourceand second payment source, wherein approval by the first payment sourceand the second payment source for the digital exchange process arereceived during the simulation; and causing, based on the simulating andin response to receiving the approval by the first payment source andthe second payment source for the digital exchange process, modificationof the first account and the second account in accordance with thetransaction amounts, wherein the modification of the first and secondaccounts occur substantially simultaneously.
 3. The data processingapparatus of claim 2, wherein the terminal device is a point of saledevice.
 4. The data processing apparatus of claim 3, wherein simulatingthe digital exchange process among the plurality of networked clientdevices for allocating the transaction amounts is initiated with aphysical machine-readable device at the point of sale device.
 5. Thedata processing apparatus of claim 4, wherein the physicalmachine-readable device comprises a credit card or a debit card.
 6. Thedata processing apparatus of claim 2, wherein the securityauthentication process further comprises determining that each thepayment sources are activated.
 7. The data processing apparatus of claim2, wherein causing the modification of the first and second accountsoccurs using a delayed allocation/re-allocation technique.
 8. The dataprocessing apparatus of claim 2, wherein causing the modification of thefirst and second accounts occurs using a batch transfer technique. 9.The data processing apparatus of claim 2, wherein causing themodification of the first account and the second account occurs using apass through technique.
 10. The data processing apparatus of claim 2,the operations further comprising: generating report data representingthe modification of the first and second accounts; and sending thereport data to an interruption device configured to print the reportdata.
 11. A method for processing network data records transmitted froma plurality of remote, distributed terminal devices, comprising:receiving allocation information specifying an allocation of transactionamounts from among payment sources associated with a plurality ofnetworked client devices; simulating a digital exchange process amongthe plurality of networked client devices for allocating the transactionamounts amount a first account associated with a first client device anda second account associated with a second client device by performingoperations comprising: performing a security authentication process foreach of the first client device and the second client device of thenetworked client devices by: receiving, for each of the first clientdevice and the second client device, a geo-code indicating a location ofthat client device; receiving identifier data indicating a terminaldevice that is physically associated with the digital exchange process,the terminal device being a non-mobile device associated with alocation; determining the location of the terminal device that isphysically associated with the digital exchange process based on theidentifier data indicating the terminal device; authenticating, from thegeo-code of each of the first and second client devices, that each ofthe first and second client devices is located within a specifieddistance to the location of the terminal device that is physicallyassociated with the digital exchange process; and determining whether toallow the digital exchange process to continue when the authenticatingindicates that each of the first and second client devices is locatedwithin the specified distance to the location of the terminal devicethat is physically associated with the digital exchange process;determining, based on determining whether to allow the digital exchangeprocess to continue and based on the allocation information, thetransaction amounts for assigning to at least a first payment sourceassociated with the first client device and a second payment sourceassociated with the second client device, the first payment source andthe second payment sources included in the payment sources; andsimulating the digital exchange process among the first payment sourceand the second payment source, wherein approval by the first paymentsource and the second payment source for the digital exchange processare received during the simulation; and causing, based on the simulatingand in response to receiving the approval by the first payment sourceand the second payment source for the digital exchange process,modification of the first account and the second account in accordancewith the transaction amounts, wherein the modification of the first andsecond accounts occur substantially simultaneously.
 12. The method ofclaim 11, wherein the terminal device is a point of sale device.
 13. Themethod of claim 12, wherein simulating the digital exchange processamong the plurality of networked client devices for allocating thetransaction amounts is initiated with a physical machine-readable deviceat the point of sale device.
 14. The method of claim 13, wherein thephysical machine-readable device comprises a credit card or a debitcard.
 15. The method of claim 11, wherein the security authenticationprocess further comprises determining that each the payment sources areactivated.
 16. The method of claim 11, wherein causing the modificationof the first and second accounts occurs using a delayedallocation/re-allocation technique.
 17. The method of claim 11, whereincausing the modification of the first and second accounts occurs using abatch transfer technique.
 18. The method of claim 11, wherein causingthe modification of the first and second accounts occurs using a passthrough technique.
 19. The method of claim 11, further comprising:generating report data representing the modification of the first andsecond accounts; and sending the report data to an interruption deviceconfigured to print the report data.
 20. One or more non-transitorycomputer readable media storing instructions for processing network datarecords transmitted from a plurality of remote, distributed terminaldevices, wherein the instructions, when executed by at least oneprocessor, configured to cause the at least one processor to performoperations comprising: receiving allocation information specifying anallocation of transaction amounts from among payment sources associatedwith a plurality of networked client devices; simulating a digitalexchange process among the plurality of networked client devices forallocating the transaction amounts amount a first account associatedwith a first client device and a second account associated with a secondclient device by performing operations comprising: performing a securityauthentication process for each of the first client device and thesecond client device of the networked client devices by: receiving, foreach of the first client device and the second client device, a geo-codeindicating a location of that client device; receiving identifier dataindicating a terminal device that is physically associated with thedigital exchange process, the terminal device being a non-mobile deviceassociated with a location; determining the location of the terminaldevice that is physically associated with the digital exchange processbased on the identifier data indicating the terminal device;authenticating, from the geo-code of each of the first and second clientdevices, that each of the first and second client devices is locatedwithin a specified distance to the location of the terminal device thatis physically associated with the digital exchange process; anddetermining whether to allow the digital exchange process to continuewhen the authenticating indicates that each of the first and secondclient devices is located within the specified distance to the locationof the terminal device that is physically associated with the digitalexchange process; determining, based on determining whether to allow thedigital exchange process to continue and based on the allocationinformation, the transaction amounts for assigning to at least a firstpayment source associated with the first client device and a secondpayment source associated with the second client device, the firstpayment source and the second payment sources included in the paymentsources; and simulating the digital exchange process among the firstpayment source and the second payment source, wherein approval by thefirst payment source and the second payment source for the digitalexchange process are received during the simulation; and causing, basedon the simulating and in response to receiving the approval by the firstpayment source and the second payment source for the digital exchangeprocess, modification of the first account and the second account inaccordance with the transaction amounts, wherein the modification of thefirst and second accounts occur substantially simultaneously.
 21. Theone or more non-transitory computer readable media of claim 20, theoperations further comprising: generating report data representing themodification of the first and second accounts; and sending the reportdata to an interruption device configured to print the report data.